用 NTS 保證 NTP 的安全

許多計算機使用 網路時間協議 Network Time Protocol （NTP）通過互聯網來同步系統時鐘。NTP 是少數幾個仍在普遍使用的不安全的互聯網協議之一。攻擊者如果能夠觀察到客戶端和伺服器之間的網路流量，就可以向客戶端提供虛假的數據，並根據客戶端的實現和配置，強迫其將系統時鐘設置為任何時間和日期。如果客戶端的系統時鐘不準確，一些程序和服務就可能無法工作。例如，如果根據客戶端的系統時鐘，Web 伺服器的證書似乎已經過期，Web 瀏覽器將無法正常工作。可以使用 網路時間安全 Network Time Security （NTS）來保證 NTP 的安全。

Fedora 33 ^[1] 是第一個支持 NTS 的 Fedora 版本。NTS 是一種新的 NTP 驗證機制。它使客戶端能夠驗證它們從伺服器接收的數據包在傳輸過程中有沒有被修改。當 NTS 啟用時，攻擊者唯一能做的就是丟棄或延遲數據包。關於 NTS 的更多細節，請參見 RFC8915。

使用對稱密鑰可以很好地保證 NTP 的安全。遺憾的是，伺服器必須為每個客戶端配備不同的密鑰，而且密鑰必須安全地分發才行。這對於本地網路上的私有伺服器來說可能是實用的，但它不能擴展到有著數百萬客戶端的公共伺服器上。

NTS 包括一個 密鑰建立 Key Establishment （NTS-KE）協議，它可以自動創建伺服器與其客戶端之間使用的加密密鑰。它在 TCP 埠 4460 上使用 傳輸層安全 Transport Layer Security （TLS）。它被設計成可以擴展到非常多的客戶端，而對準確性的影響最小。伺服器不需要保存任何客戶端特定的狀態。它為客戶提供 cookie，cookie 是加密的，包含驗證 NTP 數據包所需的密鑰。隱私是 NTS 的目標之一。客戶端在每次伺服器響應時都會得到一個新的 cookie，所以它不必重複使用 cookie。這可以防止被動觀察者跟蹤在網路之間遷移的客戶端。

Fedora 中默認的 NTP 客戶端是 Chrony。Chrony 在 4.0 版本中增加了 NTS 支持，但並沒有改變默認配置。Chrony 仍然使用 pool.ntp.org 項目中的公共伺服器，而且默認情況下 NTS 沒有啟用。

目前，支持 NTS 的公共 NTP 伺服器非常少。兩個主要的提供商是 Cloudflare 和 Netnod。Cloudflare 伺服器分布在世界各地的不同地方。他們使用的是 任播 anycast 地址，應該可以讓大多數客戶到達一個接近的伺服器。Netnod 伺服器位於瑞典。在未來，我們可能會看到更多支持 NTS 的公共 NTP 伺服器。

為了獲得最佳的可靠性，配置 NTP 客戶端的一般建議是至少有三個工作的伺服器。為了達到最好的精度，建議選擇距離較近的伺服器，以減少網路延遲和非對稱網路路由造成的不對稱性。如果你不關心細粒度的精度，你可以忽略這個建議，使用任何你信任的 NTS 伺服器，無論它們位於哪裡。

如果你確實想要高準確度，但又沒有近距離的 NTS 伺服器，你可以將遠處的 NTS 伺服器和近處的非 NTS 伺服器混合使用。但是，這樣的配置不如只使用 NTS 伺服器的配置安全。攻擊者仍然不能強迫客戶機接受任意時間，但他們確實對客戶機的時鐘及其估計精度有更大的控制權，這在某些環境下可能是不可接受的。

在安裝程序中啟用客戶端 NTS

安裝 Fedora 33 時，你可以在「Time & Date」對話框的「Network Time」配置中啟用 NTS。在點擊「+」（添加）按鈕之前，請輸入伺服器的名稱並檢查 NTS 支持情況。你可以添加一個或多個具有 NTS 的伺服器或池。要刪除默認的伺服器池（2.fedora.pool.ntp.org），請取消選中「Use」列中的相應標記。

在配置文件中啟用客戶端 NTS

如果你從之前的 Fedora 版本升級，或者你沒有在安裝程序中啟用 NTS，你可以直接在 /etc/chrony.conf 中啟用 NTS。除了推薦的 iburst 選項外，還可以對指定伺服器使用 nts 選項。例如：

server time.cloudflare.com iburst nts
server nts.sth1.ntp.se iburst nts
server nts.sth2.ntp.se iburst nts

你還應該允許客戶端將 NTS 密鑰和 cookie 保存到磁碟上，這樣它就不必在每次啟動時重複 NTS-KE 會話。在 chrony.conf 中添加以下一行，如果還沒有的話：

ntsdumpdir /var/lib/chrony

如果不想讓 DHCP 提供的 NTP 伺服器與你指定的伺服器混在一起，請在 chrony.conf 中刪除或注釋以下一行：

sourcedir /run/chrony-dhcp

當你完成編輯 chrony.conf 後，保存你的更改並重新啟動 chronyd 服務：

systemctl restart chronyd

檢查客戶端狀態

在 root 用戶下運行以下命令，檢查 NTS 密鑰建立是否成功：

# chronyc -N authdata
Name/IP address             Mode KeyID Type KLen Last Atmp  NAK Cook CLen
=========================================================================
time.cloudflare.com          NTS     1   15  256  33m    0    0    8  100
nts.sth1.ntp.se              NTS     1   15  256  33m    0    0    8  100
nts.sth2.ntp.se              NTS     1   15  256  33m    0    0    8  100

KeyID、Type 和 KLen 列應該有非零值。如果它們為零，請檢查系統日誌中是否有來自 chronyd 的錯誤信息。一個可能的故障原因是防火牆阻止了客戶端與伺服器的 TCP 埠（埠 4460）的連接。

另一個可能的故障原因是由於客戶機的時鐘錯誤而導致證書無法驗證。這是 NTS 的先有雞還是先有蛋的問題。你可能需要手動修正日期或暫時禁用 NTS，以使 NTS 正常工作。如果你的電腦有實時時鐘，幾乎所有的電腦都有，而且有好的電池做備份，這種操作應該只需要一次。

如果計算機沒有實時時鐘或電池，就像一些常見的小型 ARM 計算機（如樹莓派）那樣，你可以在 /etc/sysconfig/chronyd 中添加 -s 選項來恢復上次關機或重啟時保存的時間。時鐘會落後於真實時間，但如果電腦沒有關機太久，伺服器的證書也沒有在離到期時間太近的時候更新，應該足以讓時間檢查成功。作為最後的手段，你可以用 nocerttimecheck 指令禁用時間檢查。詳情請參見chrony.conf(5) 手冊頁。

運行下面的命令來確認客戶端是否在進行 NTP 測量：

# chronyc -N sources
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* time.cloudflare.com           3   6   377    45   +355us[ +375us] +/-   11ms
^+ nts.sth1.ntp.se               1   6   377    44   +237us[ +237us] +/-   23ms
^+ nts.sth2.ntp.se               1   6   377    44   -170us[ -170us] +/-   22ms

Reach 列應該有一個非零值，最好是 377。上圖所示的值 377 是一個八進位數，它表示最後八個請求都有有效的響應。如果啟用了 NTS 的話，驗證檢查將包括 NTS 認證。如果該值一直很少或從未達到 377，則表明 NTP 請求或響應在網路中丟失了。眾所周知，一些主要的網路運營商有中間設備，它可以阻止或限制大的 NTP 數據包的速率，以緩解利用 ntpd 的監控協議進行的放大攻擊。不幸的是，這影響了受 NTS 保護的 NTP 數據包，儘管它們不會引起任何放大。NTP 工作組正在考慮為 NTP 提供一個替代埠，作為解決這個問題的辦法。

在伺服器上啟用 NTS

如果你有自己的 NTP 伺服器，運行著 chronyd，你可以啟用伺服器的 NTS 支持，讓它的客戶端安全同步。如果該伺服器是其他伺服器的客戶端，它應該使用 NTS 或對稱密鑰與之同步。客戶端假設同步鏈在所有伺服器到主時間伺服器之間是安全的。

啟用伺服器 NTS 類似於在 Web 伺服器上啟用 HTTPS。你只需要一個私鑰和證書。例如，證書可以由 Let's Encrypt 權威機構使用 certbot 工具簽署。當你有了密鑰和證書文件（包括中間證書），在 chrony.conf 中用以下指令指定它們：

ntsserverkey /etc/pki/tls/private/foo.example.net.key
ntsservercert /etc/pki/tls/certs/foo.example.net.crt

確保之前在客戶端配置中提到的 ntsdumpdir 指令存在於 chrony.conf 中。它允許伺服器將其密鑰保存到磁碟上，這樣伺服器的客戶端在重啟伺服器時就不必獲取新的密鑰和 cookie 了。

重新啟動 chronyd 服務：

systemctl restart chronyd

如果系統日誌中沒有來自 chronyd 的錯誤信息，那麼它應該是可以接受客戶端連接的，如果伺服器有防火牆，則需要同時允許 UDP 123 和 TCP 4460 埠的 NTP 和 NTS-KE 服務。

你可以用下面的命令在客戶端機器上進行快速測試：

$ chronyd -Q -t 3 'server foo.example.net iburst nts maxsamples 1'
2020-10-13T12:00:52Z chronyd version 4.0 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 +DEBUG)
2020-10-13T12:00:52Z Disabled control of system clock
2020-10-13T12:00:55Z System clock wrong by -0.001032 seconds (ignored)
2020-10-13T12:00:55Z chronyd exiting

如果你看到一個「System clock wrong」消息，說明它是正確工作的。

在伺服器上，你可以使用下面的命令來檢查它已經處理了多少個 NTS-KE 連接和認證的 NTP 數據包：

# chronyc serverstats
NTP packets received       : 2143106240
NTP packets dropped        : 117180834
Command packets received   : 16819527
Command packets dropped    : 0
Client log records dropped : 574257223
NTS-KE connections accepted: 104
NTS-KE connections dropped : 0
Authenticated NTP packets  : 52139

如果你看到非零的 「NTS-KE connections accepted」 和 「Authenticated NTP packets」，這意味著至少有一些客戶端能夠連接到 NTS-KE 埠，並發送一個認證的 NTP 請求。

1. Fedora 33 Beta 安裝程序包含一個較舊的 Chrony 預發布版本，它不能與當前的 NTS 伺服器一起工作，因為 NTS-KE 埠已經改變。因此，在安裝程序中的網路時間配置中，伺服器總是顯示為不工作。安裝後，需要更新 chrony 包，才能與當前的伺服器配合使用。 ↩︎

via: https://fedoramagazine.org/secure-ntp-with-nts/

作者：Miroslav Lichvar 選題：lujun9972 譯者：wxy 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive